THE  ARMY  MATERIEL  DEVELOPER'S  PROJECT  MANAGER  AND  THE  COMBAT  DE— ETC(U) 
NOV  77  B R HUOOINS 


D€f^eM9€  W9T€M9 


S nHMHG€M€MT  COLL€G€ 

«) 

\ 

§ PROGMM  ri/lMG€M€l1T  COUR9€ 

I inDNIDU/(lL  9rUDY  PROGRAlM 


K)RT  BeiVIOIR.  VlIRCItIM  92060 


security  CLASSIEICATION  or  this  RAOE  (ini«n  Dim  Bnimrmd) 


DEFENSE  SYSTEMS  MANAGEMENT  COLLEGE 


STUDY  TITLE:  The  Army  Materiel  Developer's  Project  Manager 
and  The  Combat  Developer's  System  Manager: 

An  Evaluation 


STUDY  PROJECT  GOALS:  To  identify,  define  and  evaluate  user  responsibilities 

in  the  materiel  acquisition  process  and  develop  a 
procedure  whereby  these  responsibilities  could  be  co- 
ordinated and  controlled  by  the  designated  Project 
Manager. 


STUDY  REPORT  ABSTRACT:  This  report  describes  the  authority  and  responsibility 
of  both  the  Project  Manager  (PM)  and  the  TRADOC  SYSTEM  MANAGER  (TSM) 
to  determine  how  these  two  managers  should  interface  and  likely  pro- 
blems which  can  develop.  The  report  concludes  that  the  TSM  concept 
is  valid  and  if  implemented  in  such  a manner  that  the  PM  can  still 
control  his  system,  will  improve  the  materiel  acquisition  process. 

The  study  concludes  with  a list  of  recommendations 
which  can  serve  as  areas  for  more  detailed  study  and  policy  develop- 
ment. It  is  expected  that  this  report  can  be  useful  to  both  the 
materiel  and  combat  development  communities. 

SUBJECT  DESCRIPTORS:  TRADOC  System  Manager;  Materiel  Developer; 

Total  System  Development;  Combat  Developer 


NAME,  RANK,  SERVICE  CLASS  DATE 

Bobby  R.  Huggins,  LTC  (P),  USA  PMC  77-2  1 November  1977 


□ O 


r 


THE  ARMY  MATERIEL  DEVELOPER'S  PROJECT  MANAGER 
AND  THE  COMBAT  DEVELOPER'S  SYSTEM  MANAGER; 

AN  EVALUATION 

Individual  Study  Program 
Study  Project  Report 
Prepared  as  a Formal  Report 


Defense  Systems  Management  College 
Program  Management  Course 
Class  77-2 


by 

Bobby  R.  Huggins 
LTC  (P)  USA 

November  1977 

< Study  Project  Advisor 

LTC  Richard  Skowronek,  USA 

This  study  project  report  represents  the  views,  conclusions  and  recommendations 
of  the  author  and  does  not  necessarily  reflect  the  official  opinion  of  the 
Defense  Systems  Management  College  or  the  Department  of  Defense. 


I 


EXECUTIVE  SUMMARY 


The  purpose  of  this  report  is  to  evaluate  the  Army  materiel  acquisition 
process  to  determine  if  the  new  TRADOC  System  Manager  (TSM)  is  required  and 
if  so,  what  specific  functions  he  should  perform.  The  report  utilizes  inf or 
mation  from  draft  literature  and  interviews  with  PMs  and  TSMs  to  develop  the 
TSM's  duties,  how  he  should  interface  with  the  PM,  and  likely  problems  which 
can  develop. 

The  study  concludes  with  a list  of  recommendations  which  can  serve  as 
areas  for  more  detailed  study  and  policy  development.  The  major  recommenda- 
tion is  that  the  TSM  concept  be  adopted  for  all  major  acquisition  programs 
but  that  the  implementation  be  structured  in  such  a manner  that  it  will  not 
provide  grounds  for  DOD  and  Congress  to  conclude  that  the  Army  has  two  PMs 
for  each  major  program.  One  further  recommendation  is  that  the  TSM  be  iden- 
tified as  early  as  possible,  well  before  Milestone  I,  and  that  he  and  the 
PM  devise  a procedure  whereby  the  user  provides  inputs  to  the  design  process 
which  lowers  life  cycle  cost. 

It  is  expected  that  this  report  can  be  useful  to  both  the  materiel  and 
combat  development  communities.  This  report  can  also  serve  as  the  basis  for 
a new  evaluation  in  this  area  after  the  TSM  concept  has  been  fully  imple- 
mented and  experience  is  gained. 


i 


TABLE  OF  CONTENTS 


EXECUTIVE  SUMMARY  i 

TABLE  OF  CONTENTS ii 

Section 

I.  INTRODUCTION  1 

General  . 1 

Purpose  of  the  Study  Project  3 

Research  Methods  Used  3 

Organization  of  the  Report  4 

II.  THE  PROJECT  MANAGER 5 

Concept 5 

Authority  and  Responsibility  5 

Problems 7 

III.  THE  TRADOC  SYSTEM  MANAGER 10 

Concept 10 

Authority  and  Responsibility  11 

Combat  Developer/User . 12 

, Support  Package  Developer  13 

IV.  COORDINATION  REQUIREMENTS  15 

During  Concept  Development  .....  15 

After  Validation  Decision  16 

V.  POTENTIAL  PROBLEM  AREAS  19 

VI.  CONCLUSIONS  AND  RECOMMENDATIONS  21 

Conclusions  .........  21 

Recommendations  .......  23 


ii 


BIBLIOGRAPHY  24 

APPENDIX  A:  INTERVIEW  QUESTIONS  A1 

APPENDIX  B:  TRADOC  SYSTEM  MANAGER  CHARTER  B1 


Hi 


SECTION  I 


INTRODUCTION 

General 

Over  the  past  several  years,  there  has  been  a noticeable  trend  in  the 
total  Defense  Budget  toward  diminishing  constant  dollars,  increasing  per- 
sonnel cost  and  less  procurement  of  equipment.  This  situation  has  forced 
the  Department  of  Defense  (DOD)  to  realize  they  will  not  have  the  resources 
to  continue  to  do  business  as  they  have  in  the  past.  It  is  now  evident  that 
all  research,  development  and  acquisition  of  equipment  and  associated  cost 
of  ownership  of  that  equipment  or  system,  must  be  better  managed  if  the 
nation  is  to  afford  to  continue  to  defend  itself. 

In  recent  years,  primarily  since  the  early  1970' s when  Mr.  Packard 
was  the  Deputy  Secretary  of  Defense,  DOD  has  progressively  tightened  the  ma- 
teriel acquisition  process  for  major  programs.  The  present  DOD  Directives 
(DODD  5000.1  and  5000.2)  which  provide  the  broad  policy  in  this  area  have 
recently  been  republished  and  now  place  even  more  stringent  rules  on  the 
services  than  in  the  past.  The  current  major  emphasis  is  toward  total  sys- 
tem procurement,  with  the  complete  life  cycle  cost  considered  throughout  the 
process.  These  new  rules  require  that  the  services  tie  all  the  elements; 
development,  procurement,  personnel,  training  and  all  other  logistic  support 
requirements  associated  with  a new  system  into  a package,  then  determine 
the  total  cost  associated  with  that  system  before  a decision  is  made  to  con- 
tinue with  the  program.  In  other  words,  DOD  is  insisting  that  the  services 
do  a better  job  of  determining  what  they  need  and  then  developing  and  de- 
ploying a complete  system  which  can  do  the  job  and  which  can  be  afforded. 
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Throughout  the  period  since  the  late  1940's  the  Army,  like  its  sister 
services,  has  used  the  Project  Manager  (PM)  concept  in  developing  high  pri- 
ority or  urgently  needed  items  of  equipment  or  systems.  This  procurement 
scheme  placed  emphasis  on  managing  development  and  procurement  at  the  front 
end  of  the  materiel  acquisition  process.  The  track  record  shows  unequivo- 
cally that  the  PM  approach  has  improved  some  aspects  of  the  acquisition  pro- 
cess and  in  most  instances,  it  has  been  successful  in  providing  the  hardware 
so  vital  to  a sophisticated  fighting  force.  However,  all  too  often,  this 
approach  has  allowed  incomplete  products  to  be  delivered  which  could  not 
perform  up  to  expectation,  were  fielded  much  later  than  desired  or  increased 
the  already  troubled  operating  and  support  cost  more  than  necessary. 

The  current  trends  toward  more  complex  technology,  when  coupled  with 
the  increased  emphasis  on  total  system  development,  shorter  development  time 
and  lower  life  cycle  cost  has  caused  the  Army  to  conclude  that  the  PM  needs 
help  if  the  job  is  to  be  accomplished  effectively.  In  short,  the  Army  must 
develop  a complete  materiel  acquisition  process  which  effectively  integrates 
the  U.S.  Army  Materiel  Development  and  Readiness  Command's  (DARCOM)  materiel 
development  function  and  the  U.S.  Army  Training  and  Doctrine  Command's 
(TRADOC)  combat  developer/user  function. 

In  January,  1977,  the  Army  took  action  to  provide  the  PM  with  at  least 
some  of  the  help  he  needs  to  tie  the  system  together.  They  initiated  the 
TRADOC  System  Manager  (TSM)  program.  This  new  concept  is  an  attempt  by  the 
Army  to  insure  that  not  just  the  equipment  but  a complete  system  which  can 
satisfy  the  current  need  is  fielded  in  the  shortest  possible  time  and  at  the 
least  possible  cost. 
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Purpose  of  the  Study  Project 

The  purpose  of  this  study  project,  in  addition  to  expanding  the 
author's  knowledge  of  a complete  materiel  acquisition  system,  is  to  analyze 
the  new  TSM  concept.  The  PM  and  TSM  interface  and  the  problems  which  this 
marriage  can  produce  will  be  the  specific  area  of  concentration.  The  study 
is  not  intended  to  focus  on  any  one  specific  project  or  program  but  in- 
stead, will  attempt  to  address  broad  functions  which  these  two  managers  must 
perform  while  developing  and  deploying  a major  weapon  system. 

The  study  will  be  based  upon  the  author's  past  experience  as  the  staff 
officer  responsible  to  oversee  the  development  of  the  SAFEGUARD  training 
program,  draft  documentation  on  the  new  TSM  concept,  and  interviews  with 
PMs  and  TSMs  now  operating  in  the  field.  The  general  conclusions  offered 
in  this  study  can  serve  as  the  basis  for  more  detailed  studies  in  specific 
areas  which  will  result  in  an  improved  Army  materiel  acquisition  management 
system. 

Research  Methods  Used 

The  conceptual  ideas  and  data  contained  in  this  study  came  from  the 
author's  prior  experience  on  a PM's  staff  and  the  search  of  literature  re- 
lating to  this  study  area.  A significant  amount  of  the  current  thinking  on 
this  subject  came  from  seven  PMs,  six  TSMs  and  staff  officers  at  HQ  DA, 

DARCOM,  PM  offices  and  TSM  offices.  The  personal  and  telephonic  inter- 
views conducted  with  these  individuals  utilized  the  non-attribution  policy 
so  the  specific  sources  of  comments  relating  to  the  current  situation  obtained 
during  these  interviews  will  not  be  disclosed.  The  outline  by  which  these 

interviews  were  conducted  is  at  Appendix  A. 
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Organization  of  the  Report 

This  study  report  is  organized  into  sections  based  upon  the  primary 
subjects  addressed.  The  section  on  the  PM  describes  how  the  project  mana- 
ger system  has  been  working  and  identifies  the  major  shortcomings  inherent 
in  this  concept.  In  the  section  on  the  TSM,  the  primary  thrust  is  toward 
identifying  what  functions  this  individual  should  be  expected  to  perform 
and  how  he  should  interface  with  the  PM,  The  TSM  concept  is  new;  it  is  so 
new,  in  fact,  that  firm  policy  governing  this  position  has  not  been  estab- 
lished. As  a result,  the  discussion  in  this  section  is  based  upon  opinions 
and  concepts  more  than  proven  experience. 

The  remaining  three  sections  of  the  report  compare  the  proven  PM  pro- 
gram with  the  unproven  TSM  concept  and  ultimately  draw  some  broad  conclusions 
and  recommendations.  The  major  purpose  of  this  portion  of  the  report  is  tc 
identify  problems  before  they  occur  and  make  broad  recommendations  upon  which 
to  base  future  detailed  studies  and  firm  policies. 
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SECTION  II 


PROJECT  MANAGER 
Concept 

The  DOD  Materiel  Acquisition  Policy  is  that  all  major  weapon  systems 
will  be  developed  and  acquired  by  a responsible  manager  under  the  PM  con- 
cept. (10/5)^  In  the  Army,  the  PM  concept  is  based  upon  vesting  in  a sin- 
gle individual  the  sole  line  authority  for  planning,  directing,  control  of 
tasks,  and  associated  resources  involved  in  the  research,  development,  test- 
ing, initial  procurement,  production  and  fielding  of  a weapon/equipment  sys- 
tem. The  Army  PM  is  also  responsible  for  assuring  that  project  related 
planning  is  accomplished  and  executed  by  all  functional  organizations  in- 
volved with  his  program. 

Authority  and  Responsibility 

The  DOD  and  Army  materiel  acquisition  policies  are  clear  on  this  subject; 
they  hold  the  PM  responsible  for  insuring  that  a system  is  developed,  pro- 
cured and  delivered  to  the  using  organizations  within  approved  performance, 
schedule  and  cost  parameters.  This  responsibility  extends  into  every  as- 
pect of  the  particular  program  and  includes  not  only  the  equipment  which  is 
to  be  produced,  but  the  support  packages  as  well.  He  must  insure  that  a 
complete  system  is  developed  and  delivered. 

The  Army  policy  states  that  when  a PM  is  appointed  for  major  programs, 
he  will  be  given  a charter  approved  by  the  Secretary  of  the  Army  (SA)  which 

^This  notation  will  be  used  throughout  the  report  for  sources  of 
quotations  and  major  references.  The  first  number  is  the  source  listed 
in  the  bibliography.  The  second  number  is  the  page  in  the  reference. 
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prescribes  the  project  manager's  responsibility,  authority,  and  accounta- 
bility for  program  objectives  achievement.  The  charter  will  also  define 
the  line  of  authority  and  reporting  channels  between  the  PM  and  the  SA. 

The  policy  also  authorizes  the  PM  to  utilize  a direct  channel  of  communi- 
cation to  the  SA  or  lower  levels  in  the  line  of  authority,  as  appropriate, 
to  insure  that  supporting  organizations  respond  to  the  program  requirements 
as  needed.  (8-8) 

The  PM  charter  is  not  exactly  the  same  from  project  to  project  be- 
cause the  charters  must  recognize  that  programs  are  different  and  each 
requires  its  own  tailored  management  policies.  However,  most  major  system 
charters  assign  about  the  same  authority  and  responsibility  to  the  PM  as 
those  found  in  the  DARCOM  charter  for  the  XM  1 Tank.  The  broad  authori- 
ty and  responsibility  contained  in  that  charter  follows; 

-Planning,  directing,  and  controlling  the  allocation  and  utilization 
of  all  resources  authorized  for  execution  of  the  approved  project, 

-Defining,  developing,  procuring,  producing,  distributing,  and  inte- 
grating logistic  support  to  accomplish  project  objectives. 

-Achieving  the  technical  performance  objectives  of  the  project  on 
schedule  and  at  the  lowest  practical  cost. 

-Practicing  trade-offs  between  system  capability,  cost  and  schedule 
within  the  bands  of  performance  and  thresholds  established  by  the  Decision 
Coordinating  paper  (DCP)  or  the  Army  Program  Memorandum  (APM).  Trade-off 
decisions  will  give  full  consideration  to  the  effect  on  system  support 
effectiveness  and  integrated  logistics  support  resource  elements, 

-Assuring  that  total  program  planning  is  accomplished  and  that  the 

execution  of  the  project  conforms  to  the  plan.  This  includes  implementation 
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by  the  organizations  responsible  for  the  complementary  functions  of  in- 
tegrated logistic  support,  product  assurance  and  operational  testing,  and 
activation  of  deployment  of  tiic  system  and  its  related  equipment.  (4/A1-A2) 
In  short,  the  PM  is  held  accountable  for  his  system,  even  though  he 
must  rely  on  others  to  do  the  work.  He  cannot  escape  the  ultimate  responsi- 
bility for  the  results.  He  must  be  satisfied  that  what  is  done  in  his  pro- 
gram makes  sense  to  him  and  is  consistent  with  his  program  plans.  If  he 
is  not  pleased  with  progress  in  any  particular  element,  he  must  have  the 
authority  to  direct  that  it  change  and  be  brought  into  line  with  the  over- 
all plan.  (3/4-5) 

Problems 

In  today's  total  system  package,  there  are  four  broad  subsystems  which 
must  be  integrated  and  developed  in  parallel.  These  subsystems  are:  hard- 
ware and  doctrine,  logistics,  personnel  and  training.  (5/A-1-9)  The  first 
of  these,  hardware,  has  been  receiving  most  of  the  attention  and  with  some 
noted  exceptions,  have  been  fairly  well  managed.  The  last  three,  logistics, 
personnel  and  training,  which  are  in  the  main  TRADOC  responsibilities,  have 
been  poorly  managed  for  many  new  systems.  (5/A-1-9  to  A-1-14) 

The  lack  of  a complete  system  package  for  proper  testing  and  valida- 
tion during  the  full  scale  development  phase  has  caused  problems.  The 
system  must  either  enter  limited  production  and  have  additional  development 
and  operational  testing  during  the  production  phase  or  be  delayed  until 
the  support  packages  are  ready.  The  DRAGON  system  is  a good  example  where 
the  Army  let  a system  go  through  operational  test  (OT)  and  development 

lest  (DT)  without  a logistics  support  package  and  with  improperly  trained 
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personnel.  This  condition,  which  has  been  all  too  common  in  the  past,  can- 
not be  allowed  to  continue  because  it  delays  schedules  and  increases  costs 
unnecessarily.  It  must  be  noted  that  during  the  course  of  this  study,  it 
was  determined  that  the  Army  still  has  systems  which  will  undergo  DT/OT 
without  a complete  maintenance  and  training  plan.  The  Army  still  has  a pro- 
blem which  must  be  solved. 

Still  another  major  problem  area  which  is  becoming  more  critical  now  that 
greater  emphasis  is  being  placed  on  life  cycle  cost  is  how  much  impact  the 
system  design  engineer  has  on  cost.  The  big  cost  items;  training,  main- 
tenance and  manpower  must  be  considered  early  and  continuely  refined  through- 
out the  acquisition  process.  The  PM  has  not  been  extremely  successful  in 
this  area  in  most  programs.  All  too  often,  he  has  put  emphasis  on  the  low- 
est cost  production  model  and  then  brought  the  trainer  and  logistician  into 
the  program  after  the  system  design  was  set.  This  situation  means  that  not 
only  are  the  operating  and  support  (0  & S)  cost  drivers  not  considered  in 
the  early  design  phase,  but  that  the  integrated  logistics  support  (ILS) 
packages  are  started  late.  These  packages  are  not  ready  for  validation 
with  the  rest  of  the  equipment  at  OT  II  as  they  must  be.  (5/A-1-12) 

Some  of  the  PMs  interviewed  stated  that  they  are  beginning  to  go  to  the 
user  and  get  experienced  operator  personnel  to  work  with  the  contract  de- 
sign engineers.  These  efforts  have  paid  dividends  in  some  of  the  systems 
where  they  have  been  used  because  the  engineer  can  now  see,  from  the 
operator's  point  of  view,  what  causes  problems  in  the  field  and  correct  it 
very  early  while  it  is  least  expensive  to  do  so.  It  has  been  estimated 
that  as  much  as  70%  of  the  life  cycle  cost  of  a system  is  set  during  the 

early  design  stage  before  Milestone  I.  It  has  also  been  determined  that 
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a change  in  the  design  of  the  equipment,  made  after  the  basic  design  has 
been  set,  can  cost  up  to  seven  times  as  much  as  if  it  was  performed  in  the 
early  design  phase.  Under  the  new  life  cycle  cost  concept,  the  PM  must 
insure  that  the  design  engineer  is  provided  the  best  cost  impact  data,  based 
upon  user  inputs,  as  early  in  the  program  as  possible. 
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SECTION  III 


THE  TRADOC  SYSTEM  MANAGER 
Concept 

Many  of  the  current  major  problems  in  the  materiel  acquisition  process 
center  around  the  ILS  functions  which,  in  most  instances,  are  developed  and 
integrated  by  the  functional  organizations  within  TRADOC.  This  is  a large 
task  and  one  which  the  PM  has  been,  and  still  is,  responsible  for.  In 
many  instances  in  the  past,  he  concentrated  on  the  development  of  equipment 
and  the  development  of  ILS  packages  and  other  support  was  not  started  early 
enough  in  the  program.  The  PM  dealt  with  many  functional  areas,  all  too 
many  of  which  were  not  responsive  to  his  needs. 

TRADOC,  in  an  effort  to  achieve  a shorter  development  cycle  and  reduce 
life  cycle  costs,  developed  an  in-house  coordinator,  the  TSM.  This  indivi- 
dual, an  experienced  Army  Colonel,  is  expected  to  be  appointed  early  in  the 
development  cycle.  He  is  the  user  representative  who  will  help  the  PM  in- 
sure that  the  total  system,  with  all  the  necessary  support  functions,  is 
being  developed. 

In  TRADOC,  the  Army  organization  which  has  been  assigned  the  user/com- 
bat developer  role,  there  are  many  widely  dispersed  organizational  elements 
which  have  functional  responsibility  for  segments  of  the  combat  development 
mission.  The  primary  development  centers  involved  in  this  role  are:  The 
Combined  Arms  Combat  Development  Activity,  Fort  Leavenworth;  The  Logistics 
Center,  Fort  Lee;  The  Administration  Center,  Fort  Benjamin  Harrison;  The 
service  schools  such  as  The  Armor  School,  Fort  Knox;  The  Field  Artillery 
School,  Fort  Sill;  The  Infantry  School,  Fort  Benning,  and  others.  Also 
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included  in  this  process  are  the  TRADOC  test  boards  associated  with  the 
service  schools.  This  organization,  which  concentrated  the  combat  develop- 
ment expertise  in  one  location,  allows  maximum  proficiency  in  that  func- 
tional area;  however,  this  geographic  isolation  contributes  to  integration 
difficulty.  It  is  this  overall  integration  task  which  the  TSM  is  ex- 
pected to  perform.  He  must  insure  that  all  of  the  combat  development  tasks 
are  pulled  together  and  integrated,  not  only  between  themselves,  but  also 
into  the  hardware  which  the  PM  is  developing. 

Authority  and  Responsibility 

Even  though  the  TSM  concept  is  new  and  the  policies  which  will  govern 
his  actions  have  not  been  fully  developed,  the  Army  has  accepted  the  basic 
concept  and  has  taken  steps  to  implement  the  program.  The  draft  literature 
at  both  the  Department  of  the  Army  (DA)  and  TRADOC  address  the  position 
and  consider  the  authority  and  responsibility  which  this  manager  should  have. 
The  first  twenty-four  TSMs  have  been  assigned  and  another  five  are  planned 
to  begin  operating  in  the  near  future. 

The  TSM  will  derive  his  formal  authority  and  responsibility  from  a 
charter  which  will  be  similar  to  the  PMs,  with  the  exception  that  it  will 
be  approved  by  the  Commanding  General  (CG),  TRADOC,  and  not  the  SA  as  is  the 
case  with  the  PMs.  The  new  TSMs  are  in  the  process  of  preparing  their 
charters  and  at  present,  eight  have  been  approved.  The  draft  TSM  charter, 
which  was  prepared  by  TRADOC  as  a guide  for  the  new  TSM,  is  at  Appendix  B. 
This  document,  in  effect,  makes  the  TSM  another  PM  for  all  activity  con- 
cerning his  program  within  TRADOC,  and  even  extends  his  responsibility  and 

authority  to  act  for  the  CG,  TRADOC,  with  outside  agencies  such  as: 
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HQUA,  DARCOM,  OTEA,  MACOM,  MILPERCEN,  other  services  and  DOD  and  Congress, 
when  directed.  The  internal  PM  type  TSM  responsibilities  within  TRADOC  are 
unquestioned  and  all  PMs  interviewed  during  this  study  highly  endorse  this 
concept,  but  the  type  and  amount  of  authority  and  responsibility  which  the 
TSM  should  have  outside  TRADOC  is  unclear. 

The  primary  reason  for  this  unclear  condition  centers  around  the  dual 
responsibilities  which  they  must  satisfy,  that  of  the  combat  developer/user 
and  developer  for  many  of  the  ILS  packages  which  are  required  for  the  com- 
plete system.  Even  though  it  appears  that  there  is  no  major  problem  in  this 
area  at  the  present  time,  this  study  will  analyze  the  TSM's  authority  and 
responsibility  as  it  pertains  to  these  two  broad  responsibilities. 

Combat  Developer/User 


The  TSM  must  have  the  authority  and  responsibility  to  insure  that  the 
combat  development  functions  such  as  threat  analysis,  need  determination, 
and  new  doctrine/ tactics  which  pertain  to  his  system  are  developed  and  in- 
tegrated into  his  system.  Much  of  this  work  is  performed  during  the  con- 
ceptual phase,  long  before  the  PM  or  the  TSM  is  appointed,  and  serves  as 
the  basis  for  the  Letter  of  Agreement  (LOA)  and  later,  the  Required 
Operational  Capability  (ROC).  However,  the  TSM  must  insure  that  the 
functional  elements  within  TRADOC  and  at  HQDA  continue  their  work  through- 
out the  acquisition  phase.  If  it  should  be  determined  that  the  system, 
as  specified  in  the  LOA/ROC,  is  not  needed  or  the  essential  operating 
parameters  have  changed,  the  TSM  must  have  the  authority  and  responsibility 
to  report  these  findings  to  the  CG,  TRADOC,  HQDA,  and  ultimately  to  the 

SA  or  the  SECDEF  for  a decision.  This  action  is  consistent  with  the  con- 
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tractual  arrangement  between  the  combat  developer/user  and  the  materiel 
developer.  The  user  determines  that  he  needs  a new  system  to  meet  a 
specific  threat  and  then  contracts  with  the  materiel  developer  to  have 
the  system  built.  He  must  provide  the  materiel  developer,  the  PM,  with 
three  vital  pieces  of  information  which  form  the  basis  of  their  contract. 
These  guides  are:  the  selected  essential  operating  parameters  (perform- 
ance), when  the  system  is  needed  (schedule),  and  how  much  he  is  willing 
to  pay  for  the  system  (cost).  The  user  must  stand  ready  to  defend  not 
only  the  need  for  the  system  but  also,  the  development  guidelines  which 
he  has  provided  to  the  materiel  developer.  Most  of  the  PMs  interviewed 
during  this  study  endorsed  the  idea  that  the  TSM  should  be  the  individual 
to  defend  the  need  for  the  system  at  all  levels,  even  Congress,  if  required. 
The  only  PMs  who  did  not  fully  support  this  idea  did  so  because  they  felt 
that  when  the  PM  is  a general  officer  and  the  TSM  is  not,  the  PM's  greater 
rank  would  make  the  defense  easier.  Even  in  these  instances,  it  was  en- 
visioned that  the  TSM  would  be  present  and  support  the  PM  during  the  defense. 

Support  Package  Developer 

As  long  as  the  contract  between  the  user  and  the  materiel  developer, 
the  LOA/ROC,  is  valid  then  all  effort  must  be  directed  toward  meeting  the 
goals  established  therein.  This  then  forms  the  foundation  upon  which  the 
PM  works  and  he  must  coordinate  all  effort  toward  and  be  held  accountable 
for  meeting  the  terms  of  the  contract.  The  TSM  then  must  work  with  the  PM, 
serving  as  his  integrater  for  all  TRADOC  functional  areas.  This,  inci- 
dentally, is  the  mission  which  most  TSMs  interviewed  feel  is  their  primary 


responsibility  and  the  one  where  they  will  spend  most  of  their  effort, 

13 


In  this  particular  part  of  his  duties,  the  TSM  is  much  like  any 
other  PM,  he  must  coordinate  and  insure  performance  of  all  actions  which 
the  internal  TRADOC  functional  organizations  must  accomplish  in  order  to 
produce  a complete  system.  For  these  functional  areas,  the  PM  should  de- 
termine what  is  to  be  done  and  then  allow  the  TSM  to  establish  the  how  it 
will  be  done.  The  PM  will  provide  the  broad  parameters  such  as  what  functions 
must  be  performed  and  the  schedule  by  which  they  must  be  accomplished.  He 
must  insure  that  the  required  resources  are  provided  (training  devices,  pub- 
lications, test  equipment,  personnel  skills  required  and  others),  then  he 
leaves  the  TSM  alone  to  get  the  job  done.  The  PM  and  the  TSM  must  have 
agreed  upon  milestones  much  like  the  PM  should  have,  with  all  other  func- 
tional areas  associated  with  his  program.  These  milestones  must  be  tailored 
so  that  the  TRADOC  support  packages  are  completed  and  ready  for  validation 
along  with  the  rest  of  the  system.  The  TSM's  authority  and  responsibility 
for  internal  integration  must  be  strong  enough  to  allow  him  to  pull  the 
strings  required  to  get  his  part  of  the  complete  system  done  for  the  PM, 

It  should  be  noted  that  the  PMs  and  TSMs  interviewed  basicly  agree  with  the 
above  functions,  however,  since  the  TSMs  are  new  and  they  are  entering  pro- 
jects which  have  been  going  for  some  time,  it  has  not  worked  this  way  so 
far.  It  is  expected  that  new  programs  which  start  with  both  a PM  and  TSM  in 
the  early  phases  will  operate  generally  as  described  above. 
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SECTION  IV 


COORDINATION  REQUIREMENTS 
During  Concept  Development 

The  actual  coordination  requirement  between  the  material  and  the 
combat  developer  starts  long  before  either  a PM  or  a TSM  is  appointed,  The 
requirements  start  with  the  Mission  Element  Need  Statement  (MENS)  which  is 
expected  to  be  prepared  by  TRADOC  in  coordination  with  DARCOM,  Once  this 
document  is  approved  by  the  SECDEF,  a program  is  initiated  and  either  a 
Special  Task  Force  (STF)  or  a Special  Study  Group  (SSG)  is  established. 

During  this  period,  which  is  the  concept  phase  in  the  development  cycle,  it 
is  Army  policy  that  the  chairman  of  the  STF  represent  TRADOC  and  the  deputy 
be  the  PM  designee.  The  current  literature  does  not  address  the  TSM  during 
this  period,  but  one  of  the  TSMs  interviewed  stated  that  he  thought  it  would 
be  wise  to  bring  him  on  board  along  with  the  PM  designee. 

The  STF  explores  and  identifies  alternative  system  concepts,  assists 
TRADOC  in  preparing  the  initial  cost  and  effectiveness  analysis  (COEA)  and 
the  all  important  LOA.  This  group  also  assists  DARCOM  in  preparing  an  outline 
acquisition  plan  which  will  support  the  LOA  and  the  Decision  Coordination 
Paper  (DCP).  The  DCP  is  the  foundation  document  upon  which  the  validation 
decision  (Milestone  I)  is  based. 

The  work  performed  during  this  phase  of  the  acquisition  cycle  is  vital 
to  the  entire  development  of  the  system  because  it  is  during  this  phase  that 
the  one  key  document,  the  LOA  is  prepared.  This  is  the  contract  between  the 
user  and  the  developer.  It  is  the  foundation  upon  which  the  PM  will  operate 
and  can  spell  success  or  failure  to  a program.  The  LOA  must,  by  its  very 
nature,  be  broad  but  it  must  be  definitive  enough  so  the  PM  and  when  appointed 
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the  TSM  can  start  to  obtain  data  not  only  on  the  equipment  but  on  the  people, 
training,  and  logistics  support  concepts  and  requirements  as  well. 

After  Validation  Decision 

Linder  current  Army  policy,  the  PM  is  appointed  at  or  about  Milestone  I 
and  it  is  expected  that  the  TSM  will  also  be  selected  about  the  same  time  for 
all  future  major  systems.  The  two  managers  must  begin  coordination  as  early 
as  possible  during  this  phase  if  the  total  system  concept  is  to  work  properly. 
This  is  the  period  when  the  developers  start  to  look  at  alternative  solutions 
to  the  technical  problem,  and  in  many  instances,  prototypes  are  developed  and 
tested.  There  are  some  members  in  the  acquisition  community  who  state  that 
this  is  too  late  to  start  work  on  the  support  pacKages  because  the  design 
decisions  which  have  already  been  made  dictate  the  support  required  rather 
than  the  other  way  around.  (5/A-l-ll  to  A-1-14)  However,  if  he  has  not 
already  done  so,  the  TSM  must  consider  the  training  concepts,  operator  per- 
sonnel requirements  and  at  least  a desired  logistical  support  concept  if  he 
expects  to  have  these  elements  tested  at  OT/DT  I.  It  is  realized  that  these 
will  not  be  complete  packages  but  they  must  be  complete  enough  to  begin  to 
evaluate  the  approach  which  will  be  taken  in  the  later  development  phases. 

The  TSM  and  the  PM  must  also  tailor  an  agreement  which  will  allow  the 
user  to  imput  his  information  into  the  design  so  that  the  cost  drivers  are 
considered  and  the  important  ILS  packages;  logistics  support,  personnel  and 
training  are  developed  in  parallel  with  the  other  parts  of  the  system.  This 
user  input  may  range  all  the  way  from  informal  review  and  comment  on  design 
concepts  to  stationing  user  representatives  at  the  contractor's  facility. 

It  depends  on  the  system  under  development  and  the  amount  of  data  the  PM  and 
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TSM  agree  is  needed.  One  PM  even  went  so  far  that  he  sent  a prototype 
system  out  to  a unit  and  allowed  them  to  operate  and  train  with  the  equip- 
ment one  year  before  initial  operational  capability  (IOC),  This  allowed 
him  to  receive,  analyze  and  incorporate  the  users  recommendations  into  the 
system  and  lower  the  cost.  The  important  issue  is  not  how  it  is  done  but 
that  it  is  done  and  it  is  under  the  control  of  the  PM,  No  program  can  have 
two  PMs.  The  issue  of  who  will  have  final  decisions  on  critical  program  pro- 
blems such  as  engineering  change  proposals  (ECP),  system  trade-offs,  con- 
tracts, and  other  like  areas  must  be  reserved  for  the  PM  as  long  as  he  is  .. 
meeting  the  terms  of  his  contract. 

The  user/materiel  developer  relationship  during  the  design  stage  can  be 
very  critical.  It  really  depends  on  how  well  the  user  defined  what  he  wanted 
in  the  initial  contract.  If  the  user  specified  all  the  parameters  of  the  sys- 
tem, to  include  the  personnel,  training,  logistic  support  concept  desired  and 
all  others  which  he  wants  considered,  there  would  be  no  problem.  However, 
all  too  often  in  the  past,  the  user  did  not  know  what  he  wanted  and  as  a re- 
sult, changed  his  mind  throughout  the  development  cycle  or  he  sat  back  and 
received  a system  which  he  did  not  want.  The  TSM  and  the  PM  will  be  forced 
to  work  closely  to  insure  that  the  user  inputs  are  considered  and  incorporat- 
ed to  the  degree  that  they  lower  life  cycle  cost  and  those  which  would  only 
add  unnecessary  performance  at  the  expense  of  cost  and  schedule  are  rejected. 

As  the  system  progresses  through  the  development  cycle,  the  coordination 
requirements  become  even  more  critical.  The  PM  must  insure  that  the  equip- 
ment is  ready  but  under  the  current  concept,  this  is  not  good  enough.  He 
must  also  insure  that  all  other  agencies'  support  packages  are  ready.  The 
entire  ILS  package,  to  include  the  maintenance  plan,  the  logistics  support 
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system,  the  training  package,  people,  facilities,  and  the  test  plan  itself 
must  be  ready  if  a valid  test  is  to  be  conducted.  The  TSM  will  be  a great 
asset  here  because  most  of  the  critical  ILS  elements  which  must  be  tested 
are  his  responsibility.  TRADOC  is  also  responsible  for  the  development 
of  standard  scenarios  and  combat  developer  oriented/user  test  which  they 
should  provide  to  the  independent  tester,  the  U.S.  Army  Operational  Test  and 
Evaluation  Agency  (OTEA).  These  test  related  functions  have  been  neglected 
and  largely  left  up  to  the  independent  tester  in  the  past.  Of  course,  the 
TSM's  functions  are  not  complete  after  OT/DT  II.  He  must  insure  that  the 
ILS  packages  are  completed  and  ready  to  support  the  production  decision. 

One  PM  stated  that  he  has  had  problems  even  after  the  production  decision. 

He  could  not  complete  the  contract  because  the  user  did  not  know  how  many 
items  he  wanted  produced.  It  is  envisioned  that  the  TSM  is  there  to  help 
solve  just  this  type  problem. 
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SECTION  V 


POTENTIAL  PROBLEM  AREAS 

A potential  major  problem  area  which  developed  during  this  study 
centers  around  the  impression  that  the  Army  is  installing  a second  PM  in 
their  major  systems  acquisition  process.  It  was  stated  that  DOD  and  Congress 

have  bought  the  old  tried  PM  procurement  concept  and  they  should  not  be 

given  the  opportunity  to  perceive  that  the  Army  has  given  part  of  the  PM's 
power  and  responsibility  to  a second  manager.  The  PM  must  still  be  respon- 
sible for  his  system  and  the  TSM  should  in  no  way  diminish  his  responsibility 
and  authority. 

A minor  problem  which  developed  is  how  the  user  inputs  into  the  system 
design  should  be  accomplished.  There  does  not  appear  to  be  one  best  answer 
to  this  problem  which  would  apply  to  all  situations  and  systems.  It  appears 
that  the  PM  and  the  TSM  will  be  required  to  work  this  out  on  a case  by  case 

basis.  However,  it  was  determined  that  the  need  for  this  requirement  is  real 

and  it  must  be  accomplished  if  the  life  cycle  cost  is  to  be  controlled.  The 
study  did  not  reveal  that  this  is  a major  problem  at  present,  but  it  did  re- 
veal that  the  best  way  to  handle  it  was  to  identify  as  early  as  possible  and 
in  as  much  detail  as  possible  what  the  user  wanted  and  include  it  in  the  con- 
tract. We  have  a few  systems  where  this  has  been  done  in  the  last  few  years 
and  it  has  resulted  in  a much  better  and  lower  cost  product. 

Still  another  area  which  is  a problem  in  the  present  system,  but  which 
the  new  TSM  concept  has  the  potential  to  help  solve  is  the  stabilization  of 
the  user's  requirements.  The  TSM  could  help  with  this  problem  because  he 
should  be  a source  of  resistence  to  change  within  the  user  organization.  If 
the  TSM  can  hold  the  line  and  limit  the  user's  non-essential  changes,  he  can 
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be  a major  asset  to  the  PM  and  vastly  improve  the  Army  materiel  acquisi 
tion  process. 
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Conclusions 

The  TSM  concept  is  supported  by.  the  Army  Materiel  acquisition  com- 


munity; however,  it  may  not  be  supported  in  DOD  and  Congress  if  these 
organizations  perceive  that  the  TSM  has  been  given  part  of  the  PM's 
authority  and  responsibility. 


The  TSM  should  defend  the  need  for  the  systOT^^^;t,^^>,CQSt,  schedule 

;i:i' 

and  performance  requirements  in  the  ROC/LOA.  Exceptions  to  this  policy 
might  be  warranted  on  a case  by  case  basis  when  the  PM's  rank  (general 
officer)  outweighs  the  TSM's. 

The  user  has  not  properly  considered  the  0 & S cost  for  a system  fielded 
in  the  past.  The  PM  should  keep  the  TSM  fully  informed  on  the  program  so 
he  can  evaluate  the  life  cycle  cost  consequences  associated  with  trade- 
off decisions.  The  user  will  be  required  to  pay  the  bill  for  this  sys- 
tem for  many  years  after  it  is  fielded  and  he  should  have  a say  about 
how  big  that  bill  will  be.  This  process  also  should  have  a bonus 
effect  because  the  TSM  can  serve  as  a point  of  resistence  to  change  in 
the  user  community  if  he  has  full  knowledge  about  his  system. 

Milestone  I appears  to  be  too  late  to  appoint  the  TSM  because  much  of 
the  early  design  or  concept  formulation  has  been  accomplished.  He 
should  be  in  the  program  early  to  insure  that  the  cost  drivers  are  pro- 
perly considered  during  the  early  design  period. 

The  PMs  do  not  generally  have  a procedure  whereby  the  user  can  provide 
input  into  the  system  design  early  and  in  a cost  effective  way.  The 

PM  and  TSM  must  develop  a procedure  whereby  the  user  inputs,  whibh  can 
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impact  design  and  ultimately  life  cycle  cost,  are  considered  early 
and  continuously  throughout  the  development  process, 

Development  of  the  major  supoort  packages  for  which  TRADOC  is  respon- 
sible (training,  maintenance  and  personnel)  has  not  been  adequate  to 
support  the  total  system  development  concept.  The  TSM  program  should 
remedy  this  situation.  This  new  manager  must  insure  that  his  packages 
are  ready  and  tested  along  with  the  equipment. 


Recommendations 


That  the  TSM  Concept  be  implemented  for  all  major  systems,  but  that 
it  be  tailored  so  that  DOD  and  Congress  will  not  be  given  the  impression 
that  the  PM's  authority  and  responsibility  have  been  eroded. 

Appoint  the  TSM  early.  Consider  assigning  him  as  a member  of  the  STF/ 
SSG  much  in  the  same  manner  as  is  now  done  with  the  PM  designee. 

That  the  PM  and  the  TSM  develop  a procedure  to  allow  user  inputs  into 
the  design  of  the  system.  The  TSM  should  be  required  to  support  recom- 
mendations for  change  with  sound  life  cycle  cost  data  before  the  PM 
allows  the  change. 

DA  policy  should  require  that  the  TSM  defend  the  need  for  the  system  at 
all  levels,  and  that  exceptions  to  this  policy  be  granted  on  a case  by 
case  basis. 

That  the  PM  require  the  TSM  to  develop  a management  system  by  which 
all  TRADOC  functional  organizations  working  on  the  same  program  are 
controlled  and  by  which  the  PM  is  kept  informed  on  the  progress  and 
major  problems  in  each  area. 

That  the  TSM  be  included  in  all  major  system  reviews,  meetings,  and 
discussion  as  required  to  keep  him  informed  on  the  development  of  the 
total  system. 
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INTERVIEW  QUESTIONS 
APPENDIX  A 


The  questions  contained  in  this  appendix  were  used  to  gather  data  to  sup- 
port this  study  project.  In  many  instances,  the  conversations  which  these 
questions  initiated  were  much  broader  than  these  questions  would  imply. 


A-1 


INTERVIEW  QUESTIONS  FOR  PM 

1.  What  is  your  view  of  the  NEW  TSM  CONCEPT? 

2.  What  functions  do  you  envision  that  the  TSM  will  perform  in  your 
program?  (Training,  log  support  planning,  personnel,  test,  PPBS,  Eng 
Change  Proposals,  and  other) 

3.  How  are  you  communicating  with  the  TSM:  (Meetings,  reports,  in  person, 
phone?)  How  often  and  to  what  degree  do  you  expect  to  keep  him  informed 
on  your  program? 

4.  What  responsibility  and  authority  do  you  expect  the  TSM  to  have? 

A.  Internal  TRADOC  B.  External,  other  units  or  organizations  outside 
TRADOC 

5.  How  and  to  what  degree  have  you  considered  user  inputs  (comments/evalua- 
tions) in  the  design  and  development  of  your  system?  (Do  you  expect  the 
TSM  to  be  a help  in  this  area?) 

6.  Do  you  expect  the  TSM  to  defend  the  need  for  your  system?  (At  HQ  DA  in 
the  ASARC),  (DOD  in  the  DSARC),  (Before  Congress) 

7.  Do  you  see  any  problems  with  the  TSM  Concept? 
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INTERVIEW  QUESTIONS  FOR  TSM 

1.  How  long  has  your  TSM  Office  been  operating? 

2.  Do  you  have  a charter?  Has  it  been  approved? 

3.  What  project  related  authority  and  responsibility  does  your  charter 
grant  you?  (A.  Internal  to  TRADOC)  (B.  With  organizations  external 
to  TRADOC) 

4.  Have  you,  or  do  you  expect  to  be  the  individual  to  defend  the  need  for 
your  system?  (At  what  level:  DA,  DOD,  and  Congress) 

5.  What  is  your  relationship  and  how  do  you  communicate  with  the  PM  for  your 
project:  (Meetings,  reports,  in  person,  phone?)  Does  the  PM  keep  you 
posted  on  what  is  happening  in  your  program? 

6.  What  resources  do  you  expect  the  PM  to  provide  TRADOC?  (Training  equip- 
ment, contractor  training,  QQPRI,  publications,  facilities,  and  other) 

7.  How  do  you  expect  to  input  user  information  and/or  changes  into  your 
program,  particularly  for  those  elements  (equipment  changes)  which  are 
being  developed  by  the  PM  or  other  agencies  outside  TRADOC? 

8.  Do  you  foresee  any  problems  with  the  PM/TSM  Concept  on  your  project? 
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TRADOC  SYSTEM  MANAGER  (TSM)  CHARTER 

APPENDIX  B 


The  TSM  Charter  contained  in  this  appendix  is  taken  from  the  DRAFT 
TRADOC  Workbook,  "Total  System  Management",  published  3 May  77, 
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TRADOC  SYSTEM  MANAGER'S  SKELETON  CHARTER 

The  following  is  the  approved  TSM  skeleton  charter  and  is  the  primary 
guideline  for  establishing  specific  TSM  charters. 

a.  DESIGNATION  OF  TRADOC  SYSTEM  MANAGER  (TSM): 

Colonel  (name  & SSN)  is  designated  TRADOC  System  Manager  for  "X" 
system.  He  will  report  to  the  CDR  TRADOC  through  the  (center/school)  com- 
mander. This  is  the  initial  TRADOC  System  Manager  Charter  for  the  "X" 
system.  This  charter  will  be  reviewed  annually  on  its  anniversary  date 
by  the  TSM  to  insure  currency  and  adequacy.  Proposed  revisions  to  this 
charter  will  be  submitted  to  HQ  TRADOC,  ATTN:  ATCD-PM,  for  approval, 

b.  MISSION: 

The  TSM  is  responsible  for  total  system  management  for  the  "X" 
system  within  TRADOC.  He  will  insure  that  the  user  total  system  efforts 
are  developed  and  fully  integrated  early  and  continuously  throughout  the 
development  cycle. 

c.  AUTHORITY  AND  RESPONSIBILITY: 

(1)  AUTHORITY.  The  TSM,  acting  for  the  school  commandant  and  the 
Commander,  TRADOC,  will  discharge  the  user's  responsibilities  in  the  de- 
velopment, testing,  training,  and  in  coordination  with  the  gaining  command, 
fielding  of  the  "X"  system.  He  has  tasking  authority,  in  coordination 
with  HQ  TRADOC,  to  all  TRADOC  elements. 

(2)  RESPONSIBILITIES.  The  TSM  is  responsible  for; 

(a)  All  user  actions  as  delineated  in  appropriate  Army  and 
TRADOC  regulations  and  amplified  in  DAP  11-25.  In  particular,  the  TSM  will 
insure  that  plans  for  training,  personnel,  logistics  and  new  doctrine/ 
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tactics  are  timely  and  fully  integrated  into  the  materiel  development 
program. 

(b)  Primary  user  interface  with  the  PM,  "X"  system. 

(c)  Supervising  and/or  participating  in  the  preoaration  and/or 
revision  of  appropriate  materiel  requirements  documentation,  development 
plans  (training,  personnel  and  logistics)  and  testing  plans. 

(d)  Coordinating  user  evaluation  of  all  Equipment  Performance 
Reports  (EPR)  and  subsequent  proposals  for  changes  to  the  "X"  system  and 
their  relative  priorities. 

(e)  Insuring  the  compatibility  with  user  requirements  of  all 
engineering  change  proposals  (ECP)  and  other  vendor  or  PM,  "X"  system  trade- 
off proposals. 

(f)  Participating  in  the  contractual  actions  of  the  PM,  "X"  system 
to  insure  compatibility  with  user  requirements. 

(g)  Preparing  the  TRADOC  position  and  participating  in  all  decision 
reviews  ( IPR/ASARC/DSARC)  for  the  "X"  system. 

(h)  Primary  user  representation  in  all  studies,  evaluation,  and 
other  efforts  supporting  development  of  the  "X"  system. 

(i)  Defending  system  requirements  at  all  levels  of  the  DOD  and  of 
Congress  as  directed. 

(j)  Acting  as  chairman  or  co-chairman  of  all  established  "X"  system 
TRADOC/ DARCOM  JWGS. 

(k)  Insuring  development  of  training  literature,  including  crew 

and  unit  evaluation  documents,  needed  to  support  the  "X"  system  in  the  field. 

(l)  Insuring  development  of  training  standardization  for  the  "X" 

system. 
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(m)  Insuring  that  reports  in  the  progress  of  the  "X"  system  are 
provided  as  required  by  this  charter,  and  notifying  the  proponent  center/school 
commander  and  the  Commander,  TRADOC  when  it  appears  that  any  approved  pro- 
gram threshold  has  been  or  is  forecast  to  be  breached. 

d.  INTERFACE  AND  PARTICIPATING  ORGANIZATIONS; 

(1)  INTERFACE  ORGANIZATIONS.  The  TSM  is  authorized  to  coordinate 
directly  with  the  following  organizations  on  matters  relating  to  the  "X" 
system. 

HQDA 

HQ  TRADOC 

USADARCOM  PM  & MSC 

USAOTEA 

USAMACOM 

CDRMILPERCEN 

Other  services  as  required. 

(2)  PARTICIPATING  ORGANIZATIONS.  TRADOC  schools,  integrating  centers 
test  organizations  and  activities,  and  other  activities  will  provide  support 
to  the  TSM  in  accordance  with  TRADOC  regulations,  directives  and  policy/pro- 
cedure documents,  and  as  tasked  under  provisions  of  this  charter. 

e.  RESOURCE  CONTROL: 

Army  resources  to  accomplish  the  above  responsibilities  will  be  pro- 
vided directly  to  the  TSM  by  HQ  TRADOC  using  existing  funding  channels  and 
procedures. 

f.  COMMUNICATIONS  CHANNELS; 

(1)  The  TSM  is  authorized  to  exchange  direct  communications  on 
matters  relating  to  the  "X"  system  with  all  interfacing  and  participating 
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organizations. 

(2)  The  TSM  has  a direct  channel  of  communication  to  the  CG,  TRADOC 
should  any  of  the  organizations  fail  to  respond  to  system  requirements  in 
any  of  the  several  management  areas.  The  TSM  is  authorized  direct  com- 
munication with  all  participants  to  assure  timely  and  effective  direction 
and  exchange  of  information.  Prior  to  communicating  with  the  CG,  TRADOC, 
the  TSM  will  apprise  the  proponent  commander/commandant,  center/school,  of 
the  communication  to  insure  coordination  and  assistance. 

g.  LOCATION  AND  SUPPORT: 

The  TSM  office  is  established  at  the  (name  of  proponent  center/school) 
with  necessary  facilities  and  administrative  support  provided  by  that  organi- 
zation. Staffing  for  the  TSM  office  is  one  06,  one  05,  two  04,  and  one  ci- 
vilian clerk-typist  with  qualifications  and  skills  determined  by  the  proponent 
center/school  commander.  Additional  staffing  and  support  will  be  provided 
as  directed  by  the  proponent  center/school  commander. 

h.  REPORTING: 

(1)  MILESTONES.  The  TSM  will  submit  a milestone  schedule  within  30 
days  after  approval  of  this  charter,  to  include  a preliminary  status/assess- 
ment of  the  "X"  system,  and  thereafter  provide  revisions  as  required  re- 
flecting: 

ia)  The  TRADOC  System  Manager's  Office  status. 

(b)  A Schedule  of  the  significant  user  events  remaining  through- 
out the  development  cycle.  This  schedule  must  be  compatible  with  the  Master 
Milestone  Schedule  for  "X"  system  and  the  Life  Cycle  System  Management  Model. 

(c)  Recommendations  for  actions  needed  to  expedite  and  improve 
the  development  and  fielding  of  the  "X"  system. 
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(2)  REPORTS. 

(a)  An  initial  report  will  be  submitted  within  90  days  of 
office  establishment  through  DCSCD,  TRADOC  to  Commander,  TRADOC.  Reports 
will  contain  the  status  of  the  "X"  program, 

(b)  Subsequent  reports  will  be  submitted  on  an  as  needed  basis. 
Reports  will  contain  an  update  of  the  program  status,  assess  program  progress, 
and  identify  any  problem  areas  or  projected  slippage  of  major  actions  which 
affect  the  program. 

(c)  A final  report  will  be  submitted  upon  termination  of  the 
system  manager's  office. 

i.  TERMINATION: 

The  TRADOC  System  Manager's  office  will  be  terminated  when  directed 
by  the  Commander,  TRADOC. 
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